-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request reply baseline benchmark #453
Conversation
@mtmk One thing I did in my app that uses the v2 lib is to not use the built-in request-reply since it creates a new subscription for every request. I just use one subscription generating a random prefix (inbox if you will) and then reuse that subscription for all requests, appending a unique ID to the prefix, f.ex: That way my custom subscriber just has to have one active long-running ephemeral subscription to get each response for It performs a lot better than the built-in Is there a reason it currently creates a new subscription each time? |
@stebet what you're doing is sensible and we should handle it more efficiently in the library. It's not as bad at the moment since we are using a 'mux' inbox as you described, but still creating somewhat a dummy 'inbox subscription' object to handle it. So the communication with the server is optimal but internal handling still a bit costly. The reason for this approach is to generalize mux subscriptions so application code can leverage that too. e.g. if you create a subscription with the current inbox prefix, that would not create a new subscription on the server. However, this is not documented and I'm not sure if it's used at all. So the idea in this PR to make a special case for Request-Reply since it's a very common pattern (especially when using JetStream for example) and improve its 'internal' performance. Any ideas, critique welcome, as always. |
# Conflicts: # src/NATS.Client.Core/NatsConnection.cs
keeping this PR simple to a benchmark only. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
Request reply performance improvements: The basic idea is to create a shortcut to avoid additional subscriber (albeit muxed) creation so that we can save on additional allocations and potentially work. reply many can stay the same since creating a subscriber makes sense there.
This is a baseline benchmark we can merge now so that when the actual performance work is done we can have an easy way to compare results: